
Calhoun 

iniutuiiaiul AKliiv« ou tfit Nilvdl Poi($ra{jua(« School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 



Theses and Dissertations 


1. Thesis and Dissertation Collection, all items 


1995-03 

Graphical user interface design for NTCSSAM: 
shipboard administrative requirements 

Graves, Thomas C. 

Monterey, California. Naval Postgraduate School 


http://hdl.handle.net/10945/31557 


This pubiication is a work of the U.S. Government as defined in Titie 17, United 
States Code, Section 101. Copyright protection is not avaiiabie for this work in the 
United States. 

Downloaded from NPS Archive: Calhoun 



DUDLEY 

KNOX 

LIBRARY 


http://www.nps.edu/ljbrary 


CsMwun is the Naval Postgraduate School's public access distal repository for 
research oiateriels and tnstitutjiooal pubftcatiions created by the NPS community. 
Cathoufii is named for Professor of Mathematcs Guy K. CatHiuo, NPS's first 
appointed — and publi^d — scholar^ author. 

Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
MontereVr California USA 93943 



NAVAL POSTGRADUATE SCHOOL 
Monterey, California 



THESIS 


•Or-lgliial oontaias color ^ 
plates; All DIIC reproduct¬ 
ions will be in black and - 
white* 


GRAPHICAL USER INTERFACE DESIGN FOR NTCSSAM: 
SHIPBOARD ADMINISTRATIVE REQUIREMENTS 

by 

Thomas C. Graves 
March 1995 

Thesis Advisor; C. Thomas Wu 

Co-Advisor: David A. Gaitros 


Approved for public release; distribution is unlimited. 


19950824 149 





REPORT DOCUMENTATION PAGE 

Form Approved 

0MB No. 0704^0188 

Pubic reporting burden for this collection of formation is estimated to average 1 hour per response, deluding the time reviewing instructions, searching existing data sources 
gathering and maintaining the data needed, and completing and reviewing the colection of information. Send comments regardrg this burden estimate or any other aspect of this 
colection of information, including suggestions for reducing this burden to WSashington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson 

Davis Highway, Suite 1204, Arlington. VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 


3. REPORT TYPE AND DATES COVERED 

Master’s Thesis 1 

4 . TITLE AND SUBTITLE 

GRAPHICAL USER INTERFACE DESIGN FOR NTCSSAM; 
SHIPBOARD ADMINISTRATIVE REQUIREMENTS 

5. FUNDING NUMBERS 

6. AUTHOR(S) 

Thomas C. Graves 

7. PERFORMING ORGANIZATION NAMEfS) AND ADDRESS(ES) 

Naval Postgraduate School 

Monterey, CA 93943-5000 

8. PERFORMING ORGANIZATION 

REPORT NUMBER 

9. SPONSORING/ MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

10. SPONSORING/MONITORING 

AGENCY REPORT NUMBER 

11. SUPPLEMENTARY NOTES 

The views expressed in this thesis are those of the author and do not reflect the official policy or position 
of the Department of Defense or the United States Government. 

12a. DISTRIBUTION / AVAILABILITY STATEMENT 

Approved for public release; distribution is unlimited. 

12b. DISTRIBUTION CODE 

13. ABSTRACT (Maximum 200 words) 

Shipboard Naval Automated Data Processing (SNAP) is the U.S. Navy’s administrative manager for surface ships. The 
Department of the Navy is developing a replacement system, Naval Tactical Command Support System Administrative Module 
(NTCSSAM), that will upgrade the software and hardware to be more consistent with the needs of the Navy in the 21st century. 
NTCSSAM is not being developed with modem design techniques that can reduce the amount of time required to develop a 
system. This thesis will improve the development of NTCSSAM and produce a prototype representing a subset of its functionality. 

We review and analyze QFD and the Mayhew design methodologies and select the QFD tools and Mayhew phases to improve 
NTCSSAM. In addition to this, a survey form is used to compile user inputs to document improvements to NTCSSAM. To 
improve NTCSSAM we construct a prototype that includes functionalities necessary to create an enlisted evaluation. This 
prototype represents a subset of the functionalities of NTCSSAM. The prototype includes the functionality to enter crew members, 
enter command information, and edit text for creating enlisted evaluations. 

The methodology and design tools improved documentation by including all design inputs on matrices making them accessible 
to users, programers, and developers. It reduced the amount of time required to design and program functionalities for NTCSSAM 
by three weeks. The survey form produced a comprehensive list of functionalities and provided valuable user input about 
improving NTCSSAM. Using these methods to create a prototype for NTCSSAM improved the prototype’s graphical user 
interface of the prototype by including user inputs. 

14. SUBJECT TERMS 

NTCSSAM, SNAP, Graphical Design 

15. NUMBER OF PAGES 

78 

16. PRICE c6dE 

17. SECURITY CLASSIFICATION 

OF REPORT 

Unclassified 

18. SECURITY CLASSIFICATION 

OF THIS PAGE 

Unclassified 

19. SECURITY CLASSIFICATION 

OF ABSTRACT 

Unclassified 

20. LIMITATION OF ABSTRACT 

UL 


NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 


Prescribed by ANSI Std. 239-18 






























Approved for public release; distribution is unlimited 



□ □ 












ABSTRACT 


Shipboard Naval Automated Data Processing (SNAP) is the U.S. Navy’s 
administrative manager for surface ships. The Department of the Navy is developing a 
replacement system, Naval Tactical Command Support System Administrative Module 
(NTCSSAM), that will upgrade the software and hardware to be more consistent with the 
needs of the Navy in the 21st century. NTCSSAM is not being developed with modem 
design techniques that can reduce the amount of time required to develop a system. This 
thesis will improve the development of NTCSSAM and produce a prototype representing 
a subset of its functionality. 

We review and analyze QFD and the Mayhew design methodologies and select the 
QFD tools and Mayhew phases to improve NTCSSAM. In addition to this, a survey form 
is used to compile user inputs to document improvements to NTCSSAM. To improve 
NTCSSAM we construct a prototype that includes functionalities necessary to create an 
enlisted evaluation. This prototype represents a subset of the functionalities of NTCSSAM. 
The prototype includes the functionality to enter crew members, enter command 
information, and edit text for creating enlisted evaluations. 

The methodology and design tools improved documentation by including all 
design inputs on matrices making them accessible to users, programers, and developers. It 
reduced the amount of time required to design and program functionalities for NTCSSAM 
by three weeks. The survey form produced a comprehensive list of functionalities and 
provided valuable user input about improving NTCSSAM. Using these methods to create 
a prototype for NTCSSAM improved the prototype’s graphical user interface of the 
prototype by including user inputs. 
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I. INTRODUCTION 


The purpose of this thesis is to evaluate which methodologies to use for designing 
constructing and an administrative program for U.S Navy surface ships. Naval Tactical 
Command Support System Administrative Module (NTCSSAM) is a administrative 
shipboard program that is under development at NAVMASSO and intended to reduce the 
administrative burdens found on naval ships. This research will review design methods and 
the design tools that can be used in order to construct NTCSSAM. As an example of one 
of the design tools, a survey will be conducted of fleet personnel where they will indicate 
their preferences regarding various aspects of shipboard administrative management. The 
last section of the research will explain the development of an Enlisted Evaluation Program 
that prints evaluation reports for United States Navy enlisted personnel. 

The possible methodologies that could be used in the development of NTCSSAM 
will be analyzed and how these methodologies improve design. The importance of 
analyzing these design methods is to demonstrate how these methods can improve the 
required functionalities, improve the interface, and maintain an acceptable cost level of 
NTCSSAM to accomplish administrative tasks. This research reveals that using these 
proven methodologies and their tools of development on a project, such as NTCSSAM,+ 
can significantly improved the final project. These design tools allow the users and 
designers to establish the scope of the functionalities, improve documentation, and reduce 
the amount of time spent redesigning a product when conflicts arise in the design process. 

NTCSSAM is designed to completely consolidate and automate all shipboard 
administrative requirements and significantly reduce the manual administrative work load 
of fleet personnel. The initial design phases of NTCSSAM is critical to a successful and 
functional product to reduce the fleets administrative burden. As a result, a review of 
several design methods and their benefits will be provided that could improve the initial 
development of NTCSSAM. In addition to the methodologies of design a interview will be 
conducted. This interview is intended to solicit user preferences and desired functionality 


1 



to be included in NTCSSAM. As an example of the type of functionality that can be 
included in NTCSSAM, a prototype for an Enlisted Evaluation program will be developed. 
This program will also incorporate several of the design methodologies recommended for 
the design of NTCSSAM. 

A. BACKGROUND 

The amount of time shipboard personnel devote to the organization and 
dissemination of administrative information consumes an average 56 man hours per week 
updating training records alone [Ref. 1]. Reducing this time through automation would 
enable personnel to spend more time with other duties. Shipboard Naval Automated Data 
Processing (SNAP) system is the current shipboard automated system intended to assist in 
the administrative duties onboard naval ships. SNAP attempted to alleviate the burden of 
these administrative duties and was successful in several ways but not complete. 

The need for automating all the administrative facets of shipboard management and 
its advantages has been written about for many years. These needs center around saving 
time and manpower and are discussed in detail in [Ref. 1] and [Ref. 2]. Functional 
improvements to SNAP have been researched and several are described in [Ref. 1]. 
NTCSSAM is intended to automate all faces of shipboard administrative requirements and 
be a networked administrative manager that performs all the functional requirements 
needed in shipboard administration. NTCSSAM will also interact with or contain the 
functionality of the programs listed in Figure 1 on page 3. 

NTCSSAM is designed to combine all these administrative requirements under one 
system to provide administrative documentation for shipboard inspections as well as the 
frequent administrative reporting to off ship type commanders, supply departments, and 
personnel requirements. Incorporating all the functions and data included in Figure 1 on 
page 3 and other shipboard administrative requirements under NTCSSAM will reduce the 
redundancy of data and the amount of time personnel spend collecting information, 
maintaining records, preparing reports, and disseminating information to various channels. 
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B. OBJECTIVES 

This research will cover three different aspects related to NTCSSAM. The first 
aspect will be to prioritize the areas of administrative requirements listed on the survey 
form in Figure 2 on page 7. This prioritizing will represent the top four areas that the 


Source Data System (SDS) 

Uniform Military Disbursing System (UMIDS) 

Source Data System (SDS) /r.*r»TT^c\ 

Real-Time automated Personnel Identification System (RAPIDS) 

Naval Aviation Logistics Command Information System (NALCOMIS) 
Total Force Manpower Management System (TFMMS) 

SNAP Automated Medical System (SAMS) 

Dental/Medical Information System (DENMIS) 

Enlisted Distribution and Verification Report (EDVR) 

Maintenance Resource Management System (MRMS) 

Onboard Proficiently Maintenance Integration System (OPMIS) 


Figure 1: Proposed Functions/Data to be Included in NTCSSAM 


interviewed users would like to see automated in NTCSSAM. In addition users will 
indicate any specific functional description that they would like to see included in 
NTCSSAM. Second, aspects of several design methodologies will be reviewed to assist in 
organizing the functionalities required by the user. These design methods are the kind of 
design techniques that can to used in the development of NTCSSAM. These advanced 
design methodologies are recommended to establish a compatible interaciton between 
and developers. These tools or methods of design enhances the 
documentation of a project and several have been proven highly successful in modem 
commercial industry. 

These methods of design enhance the relationship between users, designers, and 
engineers ensuring the highest quality product and can be used on projects of varying size. 
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The final area of research involves the development of a smaller project using several of 
the design methods that will be discussed. This Thesis will introduce a working prototype 
of a Windows based Enlisted Evaluation Program that can be implemented into 
NTCSSAM. This includes basic design requirements, user input, development of a 
prototype, and user inputs about the prototype. This will provide specific information 
regarding a human factors analysis, what users like about the screens and functionality, of 
a Windows based Enlisted Evaluation Program. The software interface design of the 
Enlisted Evaluation Program is presented as an example of a project that has the potential 
to reduce the administrative requirements for naval personnel and how it can be emulated 
directly by the Navy and the administrative functions to be incorporated in NTCSSAM. 
Using the Enlisted Evaluation Program as an example, the documented user preferences 
can be incorporated into a networked Windows based prototype for NTCSSAM. 


C. INTERFACE DESIGN REQUIREMENTS 

The presentation of data is one of the most important considerations when 
developing a system that manipulates information and data into the desired formats to be 
displayed, reviewed, or printed. Shipboard Naval Automated Data Processing (SNAP) 
features a layered menu approach where information can be found by selecting from one 
choice on a screen cascading down to the layer that will display your information. To exit 
retracing your path is sometimes the only way to return to the main menu. A detailed 
discussion of the drawbacks and benefits of this system are presented in [Ref. 1] but it 
required more time and effort for the user who often had to memorize the path to find the 
functional screen they were looking for. Today the industry standard of windows based 
applications is so dominant that attempting to emulate any other style of interface would 
increase the initial time required to learn an application unnecessarily. One hundred percent 
of all interviews conducted with the survey form found in Figure 2 on page 7 indicated a 
familiarity with windows based applications and the use of pull down menus, further 
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supporting the use of the Windows standard. The development of NTCSSAM interface 
requirements is best represented following the standards set forth in a Windows based applications 
and is required to follow the standards as described in[Ref. 3], the government standards for 
emulating Windows environments. 

D. DESIGNING A GRAPHICAL USER INTERFACE 

Developing a graphical user interface consists of numerous facets but most of these relate 
to cost, ease of use, and functionality. It is not a simple task to require a product to perform exactly 
to the specifications, reduce the cost while making the product so intuitive and easy to use little or 
no training is required. In order to achieve these goals or even come remotely close, there is a path 
or course of action that must be taken to ensure that the desired results of minimal costs, ease of 
use and a fully functional product are achieved[Ref. 4]. The specific guidelines of constructing a 
product may depend on its size and use, but many corporations are not inventing new methods of 
how to approach design rather they are seeking the expertise of others or using a method proven 
in other corporations that have used a specific design method to improve or make a new product 
better [Ref. 5]. 

In the design of a graphical user interface there is always a trade off between cost, ease of 
use, and functionality. User interface design is a matter of compromise for powerful functionality 
with a simple clear interface. Users demand ease of use and ease of learning always at a minimal 
cost. When you design a interface conflicts between funtionality, ease of use, and cost always 
arise. These conflicts between designers, manufactures, and consumers are better solved when the 
use of some type of structured method or technique is used to assist in organizing and making the 
necessary trade-offs that inevitably arise. Not finding these conflicts before a certain stage and 
certainly before coding begins will result in one of the three facets mentioned above not meeting 
with the standards expected by the consumer. A structured method of design promotes good 
design discussions for a specific product and its users and allows for a well documented product. 

NTCSSAM is no different than any other product when it comes to the philosophy of 
design and a quality product for it users. NTCSSAM should be developed following a method or 
technique that has been used and proven in commercial industry to ensure it will meet the basic 
facets of design mentioned above. Choosing a specific method and justifying it is not a simple 
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task. Because of this, a detailed comparison of design methods will not be given. Rather a 
review of some of the techniques is better served. Of the several design methods reviewed; 

• Design methods by Mayhew 

• Developing user interfaces by Hartson and Hix 

• QFD by Bob King 

QFD offers the most detailed and documented method that is most suitable for the 
dynamic personnel structure in the Navy. This documentation is supported through the use 
of several tools for obtaining, organizing, and coordinating infomiation that must be 
applied to the design of a project. The effectiveness of QFD or managing information has 
also been demonstrated by several corporations including users form major U.S. and 
Japanese corporations [Ref. 6]. In addition to QFD the methodology of Mayhew provides 
a good structure for the overall design of a product dividing the project into five phases of 
design where specific tasks are divided among various organizations. 

E. OUTLINE 

This research presents major topics at each chapter. The major focus of this thesis 
is centered around three areas. The first is to present different types of design 
methodologies and the tools they use to improve the design and development of NTCSS. 
The second, reviews the needs of the users through a survey form found in Figure 2 on page 
7 and include a list of desired functionality from the users from this survey as depicted in 
Figure 3 on page 8. The last aspect of this thesis will discuss the construction of an Enlisted 
Evaluation Program whose functionality can be incorporated into NTCSS. A prototype of 
this Enlisted Evaluation Program is developed to illustrate the functionality desired by 
users and illustrate the enlisted evaluation program and its development using the tools of 
the design methods discussed. 
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Automating Navy Administrative Requirements 

Date:_ 

Name:_ 

Positions held:_ 

The goal of this survey is to improve the functionality of SNAP by having the users 
critique the functionality of the system. 

The use of current technology can improve SNAP so that it will manage all shipboard 
administrative data and produce required reports without all the traditional work. To this 
end, it is imperative to have the user define what a system is to do. Envision any repetitive 
reports that your chain of command wanted that left you scrambling through service 
records or old SNAP files. If all this information were available from a workstation, report 
writing would be much simpler. 

Listed below are areas of SNAP that could benefit by improving their functionality. 
Rank the 4 areas where you think improvement is most required. List any functional 
tasks that you would like to see changed or included. An example of a functional task 
is; “I would like to be able to print out a 13 week graph of someone’s PQS progress for 
their PQS tasking”. 

Maint Tickler 

Berthing Lifeboat 

Personnel (evals /edvr/lortarp) 
control 

1 ._ 

2 ._ 

3. _ 

4. _ 

3. Are you familiar with Windows based applications i.e. the use of pull down menus and 
toolbars? 

(circle one) yes no 

4. What types of software programs have you used that were designed to manage adminis¬ 
trative functions. What did you like most or dislike most about these programs.? 

5. Please give any other comments about administrative management. 


Figure 2: Survey Form for NTCSSAM 


Custom Query system Watch Bill 

Training/PQS/Schools Dep/Div 

Career Counselor/Advancement Visitor 

TASKS 
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Department division 

professional development boards 
training exercises and selex completion and tracking 
departmental tickler, project planner 
material history logs 

Training and PQS 

who’s prd is within six months 

list crew not qualified in given pqs like general dc 

track pqs for individual school 

start date, estimated completion date,% complete 
create 13 week tracking for crew individual 
track proficiency watches necessary for maintaining 
qualification 

list nec’s and crew on board that fill them filter by 
division and department 
pqs qualifiers list 
schools 

list who needs to go based on watches 
list who is leaving in 6 months and recommend 
a replacement 
availability list 

schools scheduled with prospective crew 
members for attendance 
support for gmt, departments divisional training 
yearly, quarterly, monthly and if required 
weekly training plan 

Watch Bill 

create a fire fighting and import watch bill that don’t conflict 
create under way watch bill by checking against PQS 
enter crew into watch bill then have query fill 
remaining slots 
change section of person 
enter new qualifications and schools 
print crew member with qualifications and schools 
list people by section with watch standing 
who has been to FF team trainer and what% of the 
team did it together 


Figure 3: Desired Functionality For NTCSSAM 
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Division 0£Gcer notebook/ personnel 
advancement eligibility 

what requirements need to be met pars, courses, 
leadership exam 

list where every one lives by compartment and list rack 
number 

who is eligible for mess duty 
prospective gain and losses 

generate messages for various requirements like prospective 
gain and losses 
recall bill 
ships bills 

Supply 

List all jobs with casrep parts and their status 

lis by work center, department, all or JSN 
Write CASREP message 
Lifeboat 

Life boat alpha list 
lifeboat muster list 
lifeboat 
Visitor control 

access security list 

automatic addition and deletion to master list on quarter deck 
list by name or organization 

Berthing 

list all empty racks 

list racks in a compartment with who is in them which are 
empty 

query name and indicate rack number 

Career counselor 

Advancement eligibility 

muster list, order exams 

Ships office 

mailing labels 
social roster 


Desired Functionality For NTCSSAM Continued 
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II. NTCSSAM FUNCTIONAL DEVELOPMANT 


Naval Tactical Command Support System (NTCSSAM) is the next phase in the 
development of a total shipboard automated management tool that includes maintenance, 
supply and administrative requirements for ship and soar Naval personnel. NTCSSAM is 
the new name of the system that is currently called SNAP, Shipboard Naval Automated 
Data Processing system, and whose most recent version is called SNAP HI. The first steps 
being take in the development of NTCSSAM is to review and automate the Administrative 
module of SNAP and include more advanced functionality into NTCSSAM. NTCSSAM 
administrative module is designed to reduce and automate the manual administrative work 
load both ashore and afloat. In addition to the improvements to the graphical user interface 
and functionality of SNAP, improvements will be made in updating software and hardware 
and bringing them more in-line with today’s standards. The Hardware and software 
concerns will not be discussed instead a concentration on improving the functionality of 
NTCSSAM and using an advanced design tool or methodology for construction 
NTCSSAM will be discussed 

A. DESIGN METHOD 

User interface design is an exercise in documentation and the coordination of the 
users desires. It involves trade-offs between powerful functionality and a simple and 
intuitive common sense interface. An interface should be easy to use and learn and have a 
consistent design across the interface. In addition to this performance, cost must be factored 
into design to meet the requirements of the consumer. Because these requirements conflict 
with each other and are present throughout the entire design of a product a method or 
technique is required to guide and help effectively manage the design of the user interface 
and the functionality it will posses. A good method or technique will assist in making good 
design decisions ensuring all aspects of design are meticulously compared and reviewed. 
The types of design methods that will be discussed all emphasize a structure and 
consistency in each method. Each recommends that tasks for a design method be carried 


11 


out in a particular order at certain points over the entire life-cycle of the design project and 
software development while recognizing some may be conducted in parallel. 

The design methods that are describe are a representation of the type of structure 
that can be used in the construction of a new product or upgrading a product using an 
interface design tool or method. These methods are complex and require extensive 
discussion for their implementation. The description of these methods is to give the reader 
some idea of the style and structure that is used and not a detailed analysis of its 
implementation. The details of these design methods can be found in the references for each 
respective one. 

1. Mayhew Design 

The design method describe by Deborah Mayhew consists of five phases listed in 
Figure 4. The life-cycle depicted by Mayhew is divided up into tasks delineated to specific 

1: Scoping 

2: Functional Specification 
3: Design 
4: Development 

Figure 4: Mayhew Phases of Design 

departments within an organization. All tasks (that is, not just user interface tasks) in a 
typical system development life cycle are presented in the order that they would be carried 
out, according to the responsible organization [Ref. 4]. Mayhew’s phases are best described 
with a graphical representation where interface tasks, project team responsibility, and 
interface tasks are listed as shown in Figure 5 on page 13. This figure is the graphical 
representation of the second phase of Mayhew’s design, the Functional Specification 
phase. User interface tasks are written in shaded boxes on the graph. The clear or white 




boxes represent actions required of the project team. Moving from left to right represents 
the relative time for each event. The layout of the phases in a specific order gives the 
impression that tasks are completed in a distinct order with the beginning of one relying on 
the completion of another. This is not always the case. Several of the tasks can overlap and 
can be conducted at the same time. For one thing, the different groups will have their own 
tasks to be working on. Referring back to Figure 5, the project team can be working on the 
functional specification task while the user interface group can be working on the task 
analysis. However, the user interface group must complete task analysis before beginning 
with user interface goal setting. 


Functional Specification Phase 

Adding Human Factors to 
The Software Development Process 



Figure 5: Mayhew’s Functional Phase from [Ref. 4] 

2. QFD 

Quality Function Deployment (QFD) is a design technique for integrating customer 
requirements into product design. QFD was introduced into the United States by Yoji Akao 
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in October of 1983 in the journal of the American Society of Quality Control. Since then 
major corporations such as General Electric and Ford Motor Corporation have used QFD 
to better implement consumer demands and bridge the gap between manufacturing and 
design using this method of development. QFD has proven to be excellent at integration 
new technology, managing and organizing the functionality of products and their cost. The 
main goal of QFD is to expand the time it takes to define the product but shorten the time 
it takes to make changes or redesign the product after construction. The result is intended 
to eliminate extensive redesign that costs more and takes more time than the time spent on 
the initial design phase. This design process can be represented by the drawing found in 
Figure 6. The defining of the product takes longer but the time saved in redesign results in 


Product Definition 



Figure 6: Old Design Method and QFD Design System from [Ref. 5] 


a net reduction in total product design. The time savings from using QFD can be one third 
to as much as one half the time that it would take using conventional methods [Ref. 5]. QFD 
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can be organized into four phases of planing where the seven tools of QFD are utilized to 
enhance the process. Using the seven tools of QFD, a quality matrix is constructed. It is this 
matrix of QFD which maintains the detailed documentation and acts as the support to 
bridge the gaps between design and manufacturing ensuing a quality product for the user 
and preventing extensive redesign. 

a. Four Phases of QFD 

QFD is a design process that centers on the needs of the consumer or user. 
It is designed to focus on these needs and translate them into technical specifications and 
ultimately a product. The QFD process usually occurs in four phases as depicted in Figure 
7. The first phase of QFD is “Customer Demands” or “Voice of the Consumer.” This 



Figure 7: Four Phases of QFD from [Ref. 6] 


represents the desires of the consumer or user and what they would like the product to do. 
This involves finding both the requirements the user knows about and the latent demands 
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of the user before any other step is taken. The users demands or requirements involves the 
design team having frequent discussions with current and potential users of the system. 
Determining the needs of the user are extremely necessary but are no means adequate in 
determining the scope of the products functionality. Integrating senior management and 
policy makers to determine the direction in which requirements are heading and if any new 
requirements will be required that current users are not aware of must be integrated into the 
products functionality. Phases 11 through Phase FV of the QFD Cycle rely heavily on the 
information gathered in Phase I. The remaining phases relate to parts, manufacturing, and 
the control requirements of manufacturing. In Phase 11 the key technical characteristics are 
translated into part characteristics. In Phase III of the QFD cycle, the key part 
characteristics are linked to key manufacturing operations. And in Phase IV the key 
manufacturing operations are assigned specific control requirements to insure reliability 
and consistent quality [Ref. 7]. 

b. Seven Tools of QFD 

There are seven planning tools that are used during the four phases of QFD. 
The tools are listed in Figure 8 on page 17 with a brief description of each. All of the tools 
are used for organizing and planning information necessary for design. These tools are 
different than other tools used in development because they are simple to understand and 
use [Ref. 5]. Because they are so simple more people and organizations want to use them. 

c. QFD Matrix Charts 

QFD is designed to support up to thirty matrices to organize the data that is 
collected throughout the design process. The purpose of these matrices is to allow designers 
and manufactures to work from the same set of requirements and information while 
developing each product. Each one of the matrices compare two elements of design and 
graphically represent the relationship one has with the other. Two such areas may be 
customer demands and quality characteristics. As an example we will discuss the first 
matrices that is normally developed and what tools are used to create the matrices. The first 
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step after collecting information from the consumer or user is to group his desires using an 
affinity diagram (also called a KJ Diagram). The affinity diagram organizes the users ideas 
into groups that will be placed into a column in the matrix. From each of the elements in 
the Affinity Diagram a list of Quality Elements must be listed for each one. These two 
elements, the demands of the consumer and the quality elements, are then entered into a 
matrices. The user inputs are located along the left hand side of the matrix and the quality 
elements are placed on the top of the matrix. This not only lists all the demands of the user 
but allows the comparison of these desire to be evaluated with regard to a quality element. 

1: Affinity Diagram - organizes customer demands 
2: Interrelationship Diagram- which ideas influence another idea 
3: Tree Diagram - Identifies ideas in greater and greater detail 
4: Matrix Chart - Compares ideas for correlations 
5: Matrix Data Analysis Chart - What markets to enter 
6: Process Decision Program Chart - Lists what can go wrong 
7: Arrow Diagram - Shows aspects that can be completed 
simultaneously 


Figure 8: Seven Tools of QFD 


B. QFD AND A SPECIFIC DESIGN METHOD 

The development of NTCSSAM will include communicating fleet and type 
commanders requirements to analysts and programmers that adequately describe the 
desired functionality of the new system. In addition to the requirements set forth at these 
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levels fleet personnel, or users, will evaluate the graphical interfaces for NTCSSAM while 
they are being developed to ensure that the implementation of aU functionalities is included 
and the quality of the end product meets the expectations of the users in the fleet. To act as 
a nucleus of users NAVMASSO has created a Fleet Design Team from senior enlisted 
personnel from various commands and warfare specialties to act as the embodiment of the 
users in the fleet that will use NTCSSAM. This Fleet Design team will rely on their own 
expertise of SNAP and provide the necessary inputs to analysts and programmers to ensure 
a quality product is developed. 

1. Initial Development 

The process of developing an interface with the desired functionality can seem 
rather simple. The Fleet Design Team interviews the fleet and describes what 
administrative requirements the fleet desires to designers. Programmers and designers then 
convey with each other and construct the program. After the construction of the program 
the Fleet Design Team evaluates the product for its ease of use and functionality ensuring 
it meets the specifications they desire. Are expert uses the best choice for a team of 
interviewers? Expert users may know the system but are not trained to interview people and 
may not necessarily know the technology that can influence the way questions should be 
asked [Ref. 5]. For example, does the fleet design team know how to derive the latent needs 
of the user from an interview? Does the Fleet Design Team know the spectrum of users that 
require being interviewed? Are the survey forms and interview techniques consistent so 
conflicts in functionality can easily be resolved. All these questions should be reviewed in 
detail before customers or fleet members are interviewed to obtain information. There must 
be a methodology to translate customer needs into a product and organize multiple 
departments of designers and engineers to efficiently accomplish this. 

2. Improving NTCSSAM Though Design 

The design methods listed above have been proven in the commercial world. They 
show that a structured design not only improves the product but reduces the amount of time 
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to produce it and minimizes the redesign process. NTCSSAM can benefit from these 
methods in several ways. Using trained interviewers, as recommended in [Ref. 4], one can 
better determine the users requirements while determining if the users have any latent needs 
which are not conveyed by the user. Some of the latent requirements of the user may be 
solved by the new technologies to be implemented in NTCSSAM. These technologies are 
familiar to trained interviewers where expert users of SNAP or the Fleet Design Team 
would not. A structured design method will also provide NTCSSAM with a more organized 
means of documentation. Several fleet personnel interviewed indicated sending messages 
concerning the improved functionality to SNAP n over a year ago [Ref. 8]. These inputs 
could have been consolidated and used in a survey form today and disseminated to fleet 
personnel, most of the administrative needs then are still the same today. In addition to fleet 
input, inspection teams have requirements that they are developing that can be included as 
functional tasks. These functionalities are still pertinent even though users are unaware of 
these additions today. Obtaining this type of information is discussed in [Ref. 6] where 
interviewing senior personnel and developmental personnel in an organization can reveal 
other functionalities not found form the users requests. 

C. NTCSSAM SURVEY FORM 

Surveys are one of the most common and intuitive tools to solicit large audiences 
for information regarding their demands for a system they wish developed. Surveys can be 
used to compile information or to compare various products to determine a certain level of 
quality. Surveys are a good way to collect information but they have their limitations like 
anything else. Users will not tell you everything about a product or have a limited view of 
possibilities for a product based on their limited exposure or knowledge of technological 
improvements. Revealing the customers needs or opinions is the purpose for generating a 
survey. The survey generated for NTCSSAM is intended to consolidate the customers need 
rather than their opinion of a product. 
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1. Customer Needs 

Customer demands can be divided into three areas; what customers expect but not 
tell you about, what they tell you they want and what they need but have not considered. 
This division of needs has been researched by Professor Kano in Japan where he developed 
a chart, Figure 9, to display these characteristics. The top arrow represents “exciting 



Figure 9: Customer Needs from [Ref. 9] 


quality” that producers and developers know the users need or will end up using in the 
future. The middle arrow represents “one-dimensional quality” where customers tell you 
what they want. The bottom arrow represents items that are expected. The expected aspects 
or functions are less likely, if at all, to be conveyed by the consumer to the survey or 
interviewer. 
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2. Survey Form Results 

The survey form that is shown in Figure 2 on page 5 is intended to provide 
NAVMASSO with user inputs regarding desired functionalities to be included into 
NTCSSAM. Users were also asked to prioritize areas that they would like to see improved 
by listing the top four areas they would like to see worked on and improved to become part 
of NTCSSAM. The survey revealed the four top areas in the order of highest priority first 
as; 

• Training and PQS 

• Watch Bill 

• Dept/Div 

• Maintenance 

Each of these were listed more than any of the others with Training and PQS 
receiving a higher priority than the Watch Bill. All of the surveys indicated each user being 
familiar with windows based applications. Several PC based software programs were being 
used in the fleet to assist in administrative management including TAMP for PQS and 
Training. Users also revealed they are familiar with a DOS based evaluation program but 
did not indicate the name and contended it was not user friendly. Most of the comments 
about administrative management indicated a disbelief that a SNAP based system could 
fulfill the needs of the fleet and recommended third party products that could be used on a 
networked group of PC’s. Users also listed a number of functionalities that is included in 
Figure 3 on page 9. 
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ra. CONSOLIDATED LIST OF RELATED RESEARCH 


A. THESIS RESEARCH ON TRAINING 

There are two theses that have researched the area of training for improving and 
upgrading SNAP. The first simply describes what the training requirements are for ship 
board personnel as placed on them by Type commanders in their respective fleets [Ref. 2]. 
[Ref. 2] can give the reader a consolidated report on the various requirements and what the 
reports for these requirements look like without reading the large volumes published by the 
Navy regarding this subject. The most recent research has been done by Conrad Chun and 
William Estrada in their 1992 Thesis “SNAP-III Training Administrative Subsystem 
Integrated Functional Description” [Ref. 1]. This thesis provides a functional description 
for a shipboard training administrative subsystem following the U.S. Navy Standard 
Organization and Regulations Manual. This thesis list the requirements and enhancements 
necessary to achieve a working administrative training module. 

B. ARGOS 

Argos is a system designed to facilitate the reduction of paperwork onboard Naval 
Ships. The attractive part of ARGOS is its use of a user friendly graphical user interface 
created with the software HyperCard on an Apple Macintosh. ARGOS has a tightly linked 
graphical user interface with an underlying data structure. ARGOS is being developed in 
several modules that can be combined and used for administrative requirements on Naval 
Ships. One of the major goals of ARGOS is to reduce the amount of time required to learn 
a system and make it easier to use. 

C. WINOMMS 

Winomms is another graphical user interface designed to manage maintenance 
requirements on Naval Ships. This is a Windows based application created using 
Asymmetric’s Toolbook. Toolbook is designed to allow rapid prototyping of display 
screens to create graphical interfaces. The creation of Winomms was designed to lay on top 
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of the current data structures found in SNAP and be the interface users interact with to 
obtain data and produce reports. 
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IV. ENLISTED EVALUATION PROGRAM OVERVIEW 

A. ENVIRONMENT OF EVALUATION PROGRAM 

1. Evaluation Program 

The Enlisted Evaluation Program is a Microsoft Windows application developed 
with Microsoft’s relational database software Access. Access conforms to the government 
requirements for software design listed in [Ref. 3] and is ideally suited for developing rapid 
prototypes. This rapid prototype tool is made to develope graphical user interfaces and 
combine this graphical interface with an underlying relational database. 

2. Evaluation Program Environment 

The users environment that is found in the Enlisted Evaluation Program is 
consistent with Microsoft Windows based applications. This was selected for several 
reason. This environment is required for government applications and it is an accepted 
industry standard. This standard, because of its graphical orientation, is easy to navigate 
through. Tool bars and menu bars allow the access of any task with only a few mouse 
command. Icons are used where appropriate to represent certain tasks or applications. 
These types of graphical tools allows the user to easily navigate without remembering 
numerous command line codes and typing them into a computer to access or manipulate 
information. 

3. Development Software: ACCESS 

Access is a Microsoft Windows application used for the development of 
applications that require a relational database to store and retrieve information. Access ‘s 
relational database supports the industry standard of a windows environment and 
incorporates sequel queries to retrieve information from its underlying data structure. It is 
a powerful relational database which allows the developer to create a working computer 
model, a rapid prototype, through the use of pre-defined commands and a application 
device called the “Wizard.” 
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The development of a rapid prototype using Access allows for the creation of a 
windows based application that will emulate the look and feel of other windows based 
applications. Access, or any application developed with Access, can be launched from 
within a windows environment using a pull down menu or an icon that represents that 
application. 

B. APPLICATION OF EVALUATION PROGRAM 

1. Purpose of the Enlisted Evaluation Program 

The Enlisted Evaluation Program was developed to provide a user friendly 
graphical user interface for producing U.S. Navy enlisted evaluations. The graphical 
interface incorporated as part of the Enlisted Evaluation Program is intended to reduce the 
amount of time required for training personnel to use the program and create evaluations. 
For those users who are experienced user this Enlisted Evaluation Program reduces errors 
in data entry by using pull-down menus for selecting input items and field formatting for 
data that requires entry by hand. The program also enables the use of one set of data for 
multiple evaluation thereby reducing repetitive data entry. The details of formatting and the 
use of pull-down menus will be covered in the application design phase. 

2. Problems with Current Programs 

Evaluations for enlisted personnel are usually produced using a DOS based 
application. These applications create files for each personnel that required an evaluation 
and all the information for each individual must be typed in. When creating numerous 
evaluations that all have information that is exactly the same this information must be typed 
into every evaluation. For example. Each evaluation has a block labelled “Command 
Address.” This information is the same for every evaluation in a command and using the 
DOS based programs today require this information must be typed into each evaluation. A 
relational database has the compatibility to allow the user to select the “Command 
Address” from a list, requiring no typing other than the initial one, and copy that entry into 
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the evaluation. Repetitive typing is a major draw back that can be resolved by selecting 
information from a list instead of typing it in every where it is needed in the evaluation. The 
written text that must be included in the comments section must be typed in using a word 
processor and imported into the file for each individual evaluation. This text can not be 
viewed in the DOS application for editing. Any editing must be done outside the program 
and then imported again into the DOS application. This involves the opening and closing 
of applications for each evaluation being typed. This Enlisted Evaluation Program does not 
require this constant exiting and entering but allows for the editing to occur inside the 
program using the editor of your choice. 

3. Why use the Enlisted Evaluation Program 

The Enlisted Evaluation Program is more appealing to users for several reasons. 
The program has a set of display screens that are intuitive to use making the program easy 
to learn and use. These screens are set in a Windows environment, familiar to most every 
one that uses a personnel computer. Data that is input into the program is stored in a 
relational database and can be recalled for use bye queries and subsequently used in any 
evaluation for any personnel, this allows selections to be made from pull down menus with 
the click of a mouse rather than typing in repetitive data. 
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V. ENLISTED EVALUATION PROGRAM DESIGN 


The Enlisted Evaluation Program is designed following the phases set forth in 
Debora Mayhew’s book Principles and Guidelines in Software User Interface Design, [Ref. 
4]. The phases of Scoping, Functional Specification, Design will all be addressed regarding 
the construction of the Enlisted Evaluation Program. The last two of the five phases; 
Development and Testing/Implementation have not been completed and are left for later 
research. Limiting the number of phases allows for a more manageable scope of the project 
to be completed and does not detract from the idea that a good interface design 
methodology in necessary for developing a quality product. In addition to the phases of 
Debora Mayhew several of the QFD tools will be used in gathering and organizing 
information for completing several of the phases in this research. 

A. SCOPING PHASE 

The Scoping of the Enlisted Evaluation Program involves planning the project, 
conducting a user profile and defining the hardware and software requirements. Usually a 
business definition and a business requirements analysis is conducted to begin the decision 
to develop a new product. These two documents begin the formatting of the idea to be 
developed. The need is first established and digitalis about these needs are gathered from 
marketing or users and the project plan begins to form 

1. Project Plan 

The project plan for the Enlisted Evaluation Program is not complicated or 
extensive. The development of the program is rooted in the need for a shipboard Windows 
evaluation program that would reduce the time and effort to create a new evaluation. A 
requirement analysis of several users that have experience with existing software revealed 
a dissatisfaction with the current interface and the functionalities of the programs in use. 
Staffing and cost of the project must also be considered and in the case of the Enlisted 
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Evaluation Program the staffing is one and the cost was the price of obtaining the 
developmental software, Access by Microsoft Windows. 

2. User Profile 

The users of the Enlisted Evaluation Program will be both enlisted and officers. 
These individuals are relatively computer literate, motivated, and experienced at their job. 
Generally the officers of a command complete all the details of the evaluation and a 
yeoman would check for format and fill out the summary blocks for each evaluation prior 
to having the reporting senior sign each of the evaluations. All of the users interviewed 
indicated a familiarity with Windows based applications and all of the users have a 
familiarity with personnel computers and the use of word processing software used on 
computers. Emulating the Windows environment and using familiar word processing 
software will reduce the time required to adequately learn the program. All the users 
indicated a familiarity with evaluations and the data entry fields on the forms. This 
familiarity is used to ease the learning of the programs data entry by matching the entry 
names on the computer screen to the names on the evaluations. Both ease of use and ease 
of learning will be stressed in the development of the screens of the Enlisted Evaluation 
Program. 

3. Hardware and Software Definition 

a. Hardware Requirements 

The Enlisted Evaluation requires an IBM PC compatible computer that has 
the features listed in Figure 10 on page 31. This is the minimum requirement for a 
respectable performance, any additional hardware such as a faster CPU, more RAM or 
faster hard drive will improve performance of your program. 

b. Software Requirements 

The software requirements are listed in Figure 11. The software that is used 
for word processing can very but must conform with Object Linking and Embedding 


30 




Version 2.0 (OLE 2.0). This linking standard allows a text document of the word processor 
to be stored and viewed in the database. While it is stored in the database entering and 
exiting the application is not required to view the document. 

1:386,486CPU/33MHZ 
2: 40 Megabyte Hard Drive 
3: 4 Megabytes Ram 


Figure 10: Hardware Requirements 


1: Microsoft Windows 3.X 
2: Microsoft Access 2.0 

3: Microsoft Word 3.5 (any word processor with OLE 2.0) 


Figure 11: Software Requirements 


B. FUNCTIONAL SPECIFICATION PHASE 

This phase focuses on Task Analysis, User Interface Goal Setting, and Training and 
Documentation Definition. The Task analysis was conducted with surveys of the users to 
consolidate their desires. The Task analysis also involved interviews of several users to 
reveal any latent requirements that users did not realize today’s technology offered them. 
Specifics on User Interface Goal Setting and Training and Documentation Definition were 

not analyzed. 
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1. Task Analysis 

The Task Analysis for the Enlisted Evaluation Program was conducted using 
interviews and the survey form. The input given by the users was organized into an Affinity 
diagram where the users inputs could be correlated into technical characteristics. The first 
interview process revealed the required functionality of the Enlisted Evaluation Program. 
This list produced the foundation of characteristics that the program will have. 

a. Required Functionality 

The functionality of any evaluation program must enable the user to print 
out a enlisted evaluation in the proper format with all its copies to be submitted as a final 
evaluation into a service record. The functionalities included in this program were 
compiled from user inputs as well as its designer. Although there are not many in the list in 
Figure 12 on page 33 implementing these in a graphical user interface is not a trivial matter. 
All of the required functionalities were included. Each of the functionalities listed is a 
written statement or sentence to better convey its meaning. 

b. User’s Functional Inputs of Prototype 

The user functional inputs of the prototype involve a designer showing the 
Enlisted Evaluation Program to several users for inputs on how it likes the navigational 
features, radio buttons, pull-down menus and other interface features that effect 
functionality. All of the subjects in this study were Naval officers with fleet experience. 
After reviewing the prototype the users requested the following inputs found in Figure 13 
on page 35 


32 




1: Enter ships divisions 

2: Enter ships reporting senior including full name, rank, 
title, SSN. 

3: Enter ship or station address. 

4: Enter and edit crew information including full name, 
rate, date of rate, last report date, ratings, branch or class, 
date reported, status, SSN. 

5: Create evaluations that print the form of a standard 
enlisted evaluation. 

6: Select or create more than one evaluation for a crew 
member and be able to enter or change period of report 
to, period of report from, type of report, occasion for 
report, advancement recommendation, reserve part, date 
signed, physical readiness, and all grades for the required 
categories. 

7: Enter text for duties and comments section of the 

evaluation with the capability to underline and bold face 
type any character. 

8: Enter numbers for summary information for each grade 
on the evaluation form. 

9: Print and preview drafts and final copies of the 

evaluations including the OCR, bupers, field, member, 
and activity copy in the fonts required bye the Navy. 

Figure 12: Functional Requirements 
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C. DESIGN PHASE 

The design phase involves the following user interface design methods mentioned 

bellow; 

• User Interface Mock-up 

• Style guide 

• Detailed user Interface Design 

• User interface Prototyping 

• Prototype User Interface test plan 

• Prototype User Interface Testing 

These methods of Deborah Mayhew are discussed in detail in [Ref. 4]. The first area 
of this phase involved a user interface mock up of the system. This involved the 
development of a rapid prototype using the developmental software Access By Microsoft. 
This prototype was constructed using the government style guide in [Ref. 3]. The User 
Interface Mock-up was modified to create a Detailed user Interface Design which was later 
used in the Prototype user interface testing phase. 

1. User Interface Mock-up 

This mock-up is based on the user profile, the hardware and software definition, the 
task analysis and organized in to the primary display screens the user would navigate 
through. The Style Guide method is incorporated into this phase as well and described in 
detail in [Ref. 3]. The style guide for the program was produced by the government and is 
required to be followed for developing windows based applications. The use of the rapid 
prototype software Access, allowed the User Interface Mock-up to be completed relatively 
quickly. The interface mock-up produced the look and feel of the screens but the screens 
do not have the data manipulation features of the relational database added in. These 
features are added in the detailed use interface design phase. These screens are described 
and shown in detail in the next section. 
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2. Detailed User Interface Design 

This phase incorporates the screens, user input formats, error messages, and 
complete working functionality. Again, these screens and functionalities must adhere to the 
style guide discussed earlier. All the screens in the Enlisted Evaluation Program contain 

1: When moving from front to back of evaluation have the 
individual you were working on be inunediately displayed 
so you do not need to select him from the group. 

2: Create a button that will make all the grades for an 
individual Not Observed. 

3: Be no more than three mouse clicks away from any screen. 

4: Be able to use it with any word processing software. 

5: Support importing text files and have the capability to use 
bold face text and underline characters. 

6: Use proper fonts required by Navy: OCR A and Courier. 

Be able to easily change these for new requirements. 

7: Have security so division officers can not see the file of 
someone who is not in their division. 

8: print multiple evaluations based on a division, rate, or 
period of report to date. 

Figure 13: User Inputs 


tool-bars and pull-down menus. The pull-down menus are design to maneuver from one 
screen to another with the fewest mouse movements The tool bars are designed to perform 
frequently used tasks for each of the screens. The program incorporates several screens that 
are linked together for creating an evaluation for an enlisted person. The screens are design 
so shared data can be used by everyone using the program. Enlisted evaluations contain two 


35 




types of information. Information common to all crew members and information specific 
for a certain crew member. A ships reporting senior and his pertinent information is data 
that will be found in every evaluation and be identical. The name, rank, and social security 
number of one reporting senior can be found on hundreds of evaluations and does not need 
to be typed for each evaluation. A certain crew members social security number is specific 
for that crew member. Information about the ship, its reporting seniors and evaluation 
summaries will usually be entered by Yeoman in the commands office. Data specific to a 
crew member such as their write up in the comments section and specific evaluation grades 
will be entered by the division officer or whoever is tasked to write the evaluation. All the 
necessary information necessary to produce an evaluation is provided for in the program 
and presented on the screens. 

a. Pull Down Menu Selections 

Before discussing the screens a description of the pull-down menu should 
be given. This menu is common to all the screens with very few exceptions. It was used so 
users could easily navigate to any part of the program by simply pulling down the menu 
and selecting the area they desire to go. The pull-down menu found in Figure 14 on page 
37 is representative of the menus found in all the screens. 

b. Password Screen 

The password screen is shown in Figure 15 on page 38. This screen is the 
first screen to be displayed when the ICON for the Enlisted Evaluation Program is double 
clicked with a mouse. This screen will determine whether the individual logging on will 
acquire access to the program. An individual must type in their name and password which 
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is verified with the internal listing of the same. If the password is found is granted and the 
main screen is displayed. 


Exit Personnel —> 

Ships Information ~> 

Enter or Edit Crew 

Division Names 

Evaluations —> 


Enlisted 


Print 


Summary (block 40) 


Reporting Seniors 



Figure 14: Pull-Down Menu Screen 


c. Main Screen 

The main screen is shown in Figure 16 on page 39 and opens after 
successfully logging on to the program. As displayed in the figure the user has several 
choices; editing or creating a new evaluation, enter or edit crew member, or print 
evaluations. The same commands are found in the pull-down menu but beginners who used 
the program expressed desires to have those choices prevalent when they first entered the 
system. 

d. Reporting Seniors Screen 

The reporting seniors screen is usually filled out by the commands yeoman 
or a designated administrative worker. This screen lists all the senior officers in the 
command that are eligible to be the final signature authority on enlisted evaluations. 
Reporting seniors can be added or edited from this screen and includes all of the pertinent 
information about each reporting senior that can be found on an enlisted evaluation. The 
reporting seniors screen also contains the ship or station address which will be entered on 
all evaluations. The Reporting seniors screen is presented in Figure 17 on page 41. 
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Figure 15: Password Screen 

















Figure 16; Main Screen 

































e. Evaluation Summary Screen 

All enlisted evaluations contain summary boxes that list the number of 
servicemen and women that have been ranked under a certain grade. This screen allows you 
to select the group of individuals by rank that you desire to enter summary information for. 
After selecting the rank or pay-grade, the final date of the evaluation and the number of 
servicemen and women can be entered for each grade in an evaluation. The Evaluation 
Summary Screen in Figure 18 on page 43 shows group E-7 and above and will allow you 
to enter or change the “period of report to date” and type in the number of personnel that 
are marked under each grade. The “period of report to date” is the end date of the 
evaluation. This screen will normally be filled out after all evaluations are turned in for 
final signature so a yeoman or administrative assistant will manipulate this screen. 

f. Crew Entry or Edit Screen 

The crew entry or edit screen prompts the user to select a division and crew 
member to edit or select the new record button to enter a new crew member into the 
database. New crew member can not be added to the database unless there is a minimum 
set of information to store. The program will not store a table that does not contain 
information in it. An individual must have a social security number, be part of a division, 
and have a reporting senior in order to be stored in the database. This information is 
required because the sequel queries that manipulate data require this specific data to be in 
place so the program can sort the information in the database. Several of the selections have 
pull-down menus associated with their specific data entry. These menus give the user a 
finite list of data to choose from that is required for that specific data block for a specific 
crew member. Requiring a simple selection to input text can eliminate typographical errors 
for that specific block and it can also eliminate erroneous entries. Some of the entry fields, 
like the “Date Of Rate” fields are limited in length to seven characters and require a certain 
format that must be printed on to an evaluation for it to be acceptable. The format for all 
date entries permit only seven characters to be entered. The order and type of characters 
entered begin with the last two numbers of the year followed by the first three letters of the 
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Figure 17: Reporting Seniors Screen 



















































































































































































month then the day of the year. This format will resemble this; 95MAR23. The characters 
that make up the month part in the date field are all automatically capitalized by the Enlisted 
Evaluation Program. The Enlisted Evaluation Program limits the users data entry, in the 
case of a date field, to these requirements. Other fields such as Ratings represent a pull¬ 
down menu with a finite number of selections. There are only enlisted ratings from E-1 to 
E-9 and those are the only selections a user can select from the pull down menu and have 
accepted in this data field. If a user tries to type data in that does not match one of these 
built in formats it will not be accepted by the program. This entry form is displayed in 
Figure 19 on page 44. 

g. Front of Evaluation Screen 

The front of the evaluation screens provides for pull down menus to enter 
data that has a finite number of inputs. Again the user can select an exiting crew member 
from the menus then determine whether to create a new evaluation or modify and existing 
evaluation for the crew member he has selected. The rating and division selection boxes 
generate queries to limit the names the user selects from to limit the amount of crew 
members displayed. This will prevent users from having to search through all the names in 
the crew just to find the crew member the user is looking for. Evaluations for the same crew 
member are sorted by crew name and date allowing multiple evaluations for each crew 
member. Pull-down menus are also utilized to limit the data entry selections on the front of 
the evaluation page. This screen is the first in the program to use radio buttons to reduce 
the amount of data entry. Radio buttons are used in order to complete multiple entries with 
just one command by filling in all the grading categories with “not observed” or four point 
zero grades. Although the menu bar at the top allows navigation between all screens this 
form also has command buttons that will move you to one of the next logical screens after 
editing the front of the evaluation. From this screen you are likely to edit the back or print 
out an evaluation, these buttons are located at the top of the screen in Figure 20 on page 46 
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Figure 18: Evaluation Summary Screen 







































































































































h. Back of Evaluation Screen 

The back of the evaluation was the most difficult to emulate. This screen 
involves incorporating a text editor and storing this text in the relational database. Again 
users can select the division and name of the personnel they desire to edit and the evaluation 
date for that specific crew member. Instructions at the top of the editing space instruct you 
to click you mouse in one of the boxes, either duties or comments box, and follow the 
commands to insert an object. The object that will be stored in the relational database is a 
text file created with a word processor. You will then be prompted to choose the type of 
object you wish to insert by choosing from a list of word processing software you have 
stored on your computer. The software that will be displayed in the box not only must be 
on your computer but it must support OLE 2.0. After selecting the software you will use, 
like Microsoft Word, that specific application is launched inside of the Enlisted Evaluation 
Program and is displayed in the box you clicked with your mouse. The back of the 
evaluation screen with the word processor being used is shown in Figure 21 on page 47. 
From here you enter the text in the proper format that will be printed on the back of the 
evaluation form. To exit you word processing software you click with your mouse on any 
object on the button labeled editing complete and continue with another task. 

1. Print Screen 

The print screen for evaluations was created with the same format as the 
others. Selecting the crew member to be displayed is done in the same way with division 
and rating. Following this the user can select the crew member and evaluation date to be 
printed. The users can either print or preview the front or back of the enlisted evaluations. 
The radio buttons that are labeled Evaluation Copies Front and Back are used to print out 
final copies of the evaluation. These buttons will print four copies of the evaluations final 
version. This will include the bupers, filed, activity, and members copy and the OCR copy 
of the front or back part of the evaluation. The top radio buttons labeled Evaluation Front 
and Back only print out one copy to allow revisions to be edited by hand before the final 
copies are printed.The print evaluations screen is depicted in Figure 22 on page 48. 
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Figure 20: Front of Evaluation Screen 




































































Microsoft Access - [Back of Evaluation] 
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PRI: Assistant Bachelor Quarters Officer, Managing Fifteen Separate 
Butldings totaling 244 Rooms and 10 Military Housing units-12. Supervises 
30 personnel: 12 Military and 18 Civilian-12. WATCH: OOD-12. COLL: 

Sailor of the Quarter and Sailor of the Year Board Member-12. 


|55 special achievements: 




jTo display the evaluation comments use the scroK bar to the righti 
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Received FIFTH Good Conduct award. Nai.ry rights and Responsibilities, 
Government Ethics, Sexual Harassment, HIV .Awareness Training (Aug 94) 
Completed WrdPerfect Training Workship (Jun 94) . 
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Figure 21: Back of Evaluation Screen 
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Figure 22: Print Evaluation Screen 






































D. PHASES AND METHODS NOT COVERED 

The Development and Testing/Implementation phases of Mayhew were not 
covered to minimize the scope of the research. User Interface Prototyping and Prototype 
User Interface Test Plan were also not completed because the Enlisted Evaluation Program 
does not contain all the functionality required a fully developed prototype. The program is 
fully functional and is able to receive data and organize it for printing multiple evaluations 
but there is no help screen for the program. Ideally the program should be developed with 
Microsoft’s developers tool-kit for Access. This would allow the program to run without 
having the software for Access installed on your computer. In addition, the program did not 
go through a usability test to reveal any major problems in the initial design. Final 
implementation was constricted to a few users only testing the core functionality of the 
program. 
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VI. DESIGN AND IMPLEMENTATION 


A. DESIGN GOALS AND DEVELOPMENT 

1. Design Goals 

The design goals of this research was to prototype a windows based evaluation 
program for editing and printing enlisted evaluations. This prototype needed to conform 
with government standards in [Ref. 3] at the same time maintaining a consistency among 
screens to facilitate familiarity with the program and an easy to learn graphical user 
interface. The Enlisted Evaluation Program is developed in the Microsoft Windows 
environment using the developmental database software Access. Access was ideal to use 
as a rapid prototyping tool for this application because it allows developers to create 
windows based interfaces with a underlying relational database. Access’ tools can create 
pull-down menus, radio buttons, colorful screens, and any mouse selectable option 
normally found in a windows environment. 

2. Development Goals 

The phases of development involved analysis of current windows programs, 
implementing desired functionalities, and the stmcture of the Enlisted Evaluation Program. 
Developing a program that produces an enlisted evaluation program was chosen for several 
reasons. The first of these reasons is no windows based evaluation program that uses a 
relational database and the second reason is the program has the ability to be expanded to 
support other administrative functions. The program was also chosen because it represents 
a finite goal; produce an enlisted evaluation in the proper format. The Enlisted Evaluation 
Program utilized data that is already entered in SNAP with very few exceptions. Because 
this information is present in SNAP including this type of functionality into NTCSSAM 
would not be as involved as other functionalities. 

The implementation of the functionalities was centered around reducing the 
possibilities of error that a user could make and reducing the time required to create the 
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evaluation. Reducing errors from users can be accomplished in several ways and Access 
provided for this with several of its built in tools. Entry boxes can have a format assigned 
to each box. When users are asked to type in a crew members middle initial and they type 
the number seven the field in the box does not accept the entry. Entering dates into boxes 
is also controlled by formatting the field to prevent improper entry. All the date entrees 
require two numbers followed by three letters then two numbers to result in an entry similar 
to this; 90MAR30. The entry box will automatically make the letters capitalized as required 
in the evaluation form. Another Access tool that facilitates data entry and the reduction of 
errors is a pull down list. If there is a finite number of entries for a specific box having the 
user select form those will reduce the errors of typing and format, the front of the evaluation 
has several of these type of entry boxes. The entry box “Type of Report” only has three 
possible entries for that specific box; Concurrent, Special, Separation. Just by selecting one 
of these and not typing in the field prevents erroneous errors and saves time. Time spent by 
the user filling in boxes can also be save by using a radio button to fill in numerous fields 
with one selection. Frequently commands are required to give grades of “not observed” for 
all the areas being grades. Radio buttons that fill in all thirteen fields with not observes 
reduces entry time dramatically. 

The development of the Enlisted Evaluation Program centered around the logical 
development of the screens and how data entry would be divided between them. The 
structure of the screens and the logical flow of navigating between screen is also a 
consideration for creating a program that is easy to use and learn. Each of the screens 
should be divided into logical groups of data entry and emulate the natural progression of 
constructing an evaluation in the same way you would without using a program. Creating 
a logical path for the construction of an evaluation enhances the use of the program and 
makes the program easier to learn. If the order of data input mirrors the way evaluations are 
normally constructed bye the user then creating an evaluation will be more intuitive. 
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B. IMPLEMENTATION OF DESIGN 


1. Design of Enlisted Evaluation Program 

Each of the screens developed have the same characteristics and the same 
backgrounds, headings, and pull-down menus where applicable. This includes the same 
color scheme, exit button, tool bar, and menu bar as well as other similarities. Familiarity 
among screens makes for smother navigation and friendlier environment [Ref. 10]. The 
specific design of the screens is divided into three areas of logical data entry; information 
about the command, crew information that does not change, information specific to a 
certain evaluation for that crew member. Conunand information is divided into three 
screens. One where users input information about the ship or station and the reporting 
seniors, another to input division names, and the third for evaluation summary information. 
Command information screens and some crew information does not change when creating 
a new evaluation, and in the case of command information this information can be used 
when creating any evaluation because it never changes for any crew member. For example 
the ships address is used in all evaluations. The evaluation front and back screens represent 
data specific to each evaluation for one crumblier. Crew members evaluations are identified 
by the crew members name and the date of the evaluation. A crew member will not change 
his name but different evaluations for that crew member need to be identified. The crew 
members name and date of report together separate the different evaluations for that one 
crew member. Selecting crew members for printing and editing are the same for three of 
the screens. Both the front and back evaluation screen and print screen have the identical 
display to select rating and division before selection the specific crew member. This 
duplication of format enhances familiarity with the program and how to display the desired 
information about a crew member. Command buttons are found frequently on screens and 
are used for navigation in the program and also used for action buttons for specific screens. 
The pull down menu on the top of the program screen will allow you to navigate to any 
screen in the program, but certain screens have command buttons that navigate to the next 
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logical screen when creating an evaluation. The evaluation front screen has two command 
buttons for navigation; “Edit Evaluation Back” and “Evaluations Print”. These two buttons 
were added for logical navigation. It goes to reason that after you finish with the front of 
the evaluation you will want to work on the back, if not you may want to print out what you 
have worked on. All the screens have command buttons to exit which automatically saves 
all the work you have done before leaving the Enlisted Evaluation Program. Radio buttons 
were used in two instances in the program. The Front of Evaluations screen has two radio 
buttons to make all the grades four point zero or not observed. These are the most common 
entries for evaluations and these buttons automatically make selections for each of the 
thirteen graded categories of the evaluation. The print screen also used radio buttons to 
select between four different items. These buttons allow for different options of printing 
and preview for the front and back of evaluations both for the draft and final copies. Pull¬ 
down boxes were used in numerous places in the program. The pull-down boxes are used 
for entries with a finite lists of data that is allowed in the entry box. For information you 
type in like divisions on a ship or ratings there are only a finite number of divisions and 
nine ratings that are in the Navy, E-1 to E-9. Entry boxes that can only be filled with a finite 
number of entries are best served with pull down boxes because it reduces the amount of 
typing an minimizes errors. The list in Figure 15 on page 55 represents all the objects in the 
Enlisted Evaluation Program where a pull-down box is used to select and fill in the entry 
box with data. 

Screen size is a limiting factor when determining the number of items that are 
included on one screen. Groups of data that can be organized in some logical part or that 
have a logical correlation should be placed on one screen. This grouping simulates starting 
with an idea then finishing with it before moving on to the next idea. Each one of the 
screens represent one idea and the items requiring data entry in that screen are part of that 
idea. For example the front of the evaluation screen fills in all the data that is required for 
the front of the evaluation. Users can look at the evaluation form and the evaluation screen 
and see all the items from one side of the evaluation form are present on the screen. The 
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naming of the boxes on the screen also correlate to the names of the boxes on the form to 
minimize any confusion about what information goes in what box. One of the more difficult 
design considerations was providing for the use of a text editor or a text editor capability 
while the Enlisted Evaluation Program was running. Exiting in and out of two programs to 

1: Division Name 

2: Reporting Senior 

3: Ratings 

4: Status 

5: Branch/Class 

6: Summary group 

7; Period of Report To 

8: Type of Report 

9: Occasion fro Report 

10: Advancement Recommendation 

11: Date Signed 

12: Physical Readiness 

13: All graded sections that require numeric score. 

14: Selection of rating and division 
15: Selection of crew member 


Figure 23: Evaluation Boxes with Pull-Down Menus 


edit text then manage data in a database is unacceptable. Access works its way arround this 
problem through the use of Object Linking and Embedding 2.0. This allows the user to 
manipulate text inside the program and not switch in and out to edit text. Microsoft Word 
is word processing software that sports OLE 2.0 and enables the user to edit a document 
inside of the Enlisted Evaluation Program while you are in the program. Programs with the 
capability of OLE 2.0 will behave in the same manner. The screen size that is required to 
fit the text boxes on an evaluation exceeds the size of a typical 15” computer monitor whose 
resolution is set at 800X600 dots per inch. This limitation required the use of a scroll bar to 
access both the duties and comments box found on the back of the evaluation form. 
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VII. SUMMARY OF EVALUATION PROGRAM 


A. FUNCTIONALITY NOT INCLUDED 

The functionality limitations or omissions may or may not be related to the 
limitation of the software. Some of the functionalities were not explored as a result of the 
limitations of thesis work. The fimctionalities that were not included begin with moving 
from screen to screen. When users moved from the front of the evaluation screen to the 
back of the evaluation screen the crew member you were working on the front evaluation 
screen should show up when you switch to the back of the evaluation screen. Another 
involved Inserting text required too many mouse clicks and proved to be more awkward 
when using other software that was not made by Microsoft. Word Perfect text could not be 
imported into the document only text files from word perfect could be entered into an OLE 
program and then used. Selecting more than one name for printing would allow multiple 
evaluations to be printed with only one print command. The program should allow for 
printing the final version for all evaluations of a given group, like all E-6 evaluations. The 
evaluations should print the front and back of the evaluation at the same time so the user 
does not need to flip the paper on a double sided copy. The default fonts should be 
automatically set when you open a new duties or comments box. 

B. DEVELOPMENT CONSTRAINTS 

The most notable of the limitations is the specific requirements of security for 
evaluations. Access provides for security in a manner where you either have access to a 
screen or you do not. Access will not separate and prevent two division officers from 
accessing the evaluation information of the others division. You can prevent others from 
using the program at all but there is no provision for partial security using the same queries 
and screens. Separate software, The Access Developers Kit, is required to develop just a 
run time module so the inner workings of the program cannot be changes by a system 
administrator. The graphics for the front of the evaluation requires a large amount of 
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memory do display on the screen. System crashes occurred while operating in true color 
resolution. Not all the commands are written in the object oriented program language 
provided with Access. This is required for a portable system and runtime module to be 
developed. Command employment could not be entered as a separate entity and physically 
placed in the evaluation where it belongs. Command employment is placed at the end of 
duties and responsibilities and the size of both depend on their placement. Date blocks 
could have their format better controlled. The year part of the date blocks should limit the 
input to numbers over 90 and the day part of the date box should be limited to numbers 
under 31. 
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Vin. CONCLUSION 


A. SUMMARY OF RESEARCH 

The use of a specific design methodology or design tool will greatly enhance the 
user interface of NTCSSAM’s functional development as well as the documentation 
required in user interface design. The survey forms are a good means of extracting data 
from users, senior management, and potential users but great care must be used in the 
questions that are generated. Interviews are another way to improve the design of 
NTCSSAM but the individuals conducting the interviews must be trained and experience 
at this task. It is not enough to be an expert user of the system to conduct interviews. The 
survey form in this research produced a number of functionalities from users but did not 
include inputs from senior officers or inspection teams. These are the groups that create the 
administrative requirements for the fleet and as such should be included in the process of 
design of NTCSSAM. 

The Enlisted Evaluation Program provides an example of an evaluation program 
that can be included in NTCSSAM. The complexities of this program are rooted in the 
interface with a graphical text editor and printing out the required reports in a specific 
format. The screens give a good example of how to present the data and the thesis text 
indicate a core of the functionality required. 

Using Microsoft Access 2.0 proved to be a good tool to develop a rapid prototype 
for an evaluation function. The Enlisted Evaluation Program was designed to provide the 
typical user with a more efficient way of creating and editing evaluations for service record 
entry. Access use of a relational database made the manipulation of data easier while the 
windows based presentation created a intuitive graphical interface for the user to create and 
print evaluations. 
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B. RECOMMENDATIONS 


Before the current design method is followed a review of the current methodology 
should be conducted and compared with one of the methodologies listed in the previous 
chapters. NTCSSAM is designed to relieve the administrative burden of fleet personnel. To 
best provide this a few personnel could spend a few weeks doing a survey of shore and ship 
based personnel both officers and enlisted. Find out what would reduce their administrative 
burdens or rely on the officers interviewed in this thesis and concentrate on training and 
PQS. The requirements or functionality for any administrative program should not be 
completed without a detailed review of the documentation that requires the generation of 
these requirements in the fleet. Instructions which outline these requirements are: 

• OPNAVINST 3541. ID (Shipboard Damage control Readiness) 

• OPNAVINST 354.4D (Propulsion Examining Board for Conventionally 
Powered Ships) 

• COMNAVSUFLANT/PAC 3540.1C (Engineering Department Organization 
Manual) 

• OPNAVINST 3120.32D (U.S. Navy Standard Organization and Regulations 
Manual) 

C. CONTINUED RESEARCH 

There are many possibilities for continued research and developments related to 
this thesis. NAVMASSO is currently converting the functionalities of SNAP HI and 
rewriting them in ADA to be incorporated into NTCSSAM. These functionalities or newer 
ones could be converted into ADA and demonstrated as a thesis. 

A formal design method could be implemented to create NTCSSAM and a set of 
user interface screens developed using a rapid prototyping tool, these screens could be 
displayed to the fleet and tested using a formal design methodology. 

The Enlisted Evaluation Program could be expanded in several was. functionality 
could be added to it incorporation other administrative requirements such as those listed in 
the survey form for NTCSSAM. The developers kit for Access could be used to convert the 
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Enlisted evaluation program and any other functionalities into a run time program. If a run 
time version of the program is created using the developers kit the development 
environment is not needed to run the program. 
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